Add LargeYeagerTransferCoefficients bulk flux formulation#162
Add LargeYeagerTransferCoefficients bulk flux formulation#162simone-silvestri wants to merge 18 commits intomainfrom
Conversation
15695f0 to
d99b2b6
Compare
ef91327 to
088e2dc
Compare
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
|
Initially everything was prefixed by |
|
There is a simpler, non-iterative way to implement this. See here: https://github.com/NumericalEarth/Breeze.jl/blob/main/src/BoundaryConditions/polynomial_bulk_coefficient.jl |
|
Interesting. This is a regression to approximate the iterations looks like? We can also add this formulation to the model, that fits very cleanly with the For OMIP compliance we need the iterative fluxes unfortunately to be exactly equal to the OMIP2 procedure. I would like to make sure the biases are not because of different forcing. I think I can add this whole machinery by just making some changes to generalize the |
Introduce `CoefficientBasedFluxes` with a unified `transfer_coefficients` interface that accepts either `SimilarityScales` (constant or callable coefficients) or `LargeYeagerTransferCoefficients` (full L&Y 2004/2009 stability-corrected algorithm). Add `PolynomialNeutralDragCoefficient`, `LinearStableStabilityFunction`, and `large_yeager_stability_functions`. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
642288c to
92e3a7c
Compare
|
Ok, this might be better now. |
It's a regression to the bulk Ri and stability parameter. If the stability parameter is known then the fluxes can be evaluated directly with no iteration. I guess it is simply an approximation solution to the flux inversion. It's fairly accurate as demonstrated by that paper. The question is basically how many flux models we need? If we want something that uses polynomials approximations, it might make sense to go all the way to avoiding iteration. But I understand if you really need LY09 exactly. |
|
I agree that maybe that formulation is probably better since it is a single sweep. I can test the difference and see if we can just keep the simple one-shot formulation. I have restructured the PR to use |
oh neat |
|
These new fluxes can be seen in action here https://numericalearth.github.io/NumericalEarthDocumentation/previews/PR162/interface_fluxes/ |

Summary
Refactor
CoefficientBasedFluxesto cleanly support the Large & Yeager (2004, 2009)stability-corrected bulk algorithm alongside constant and polynomial coefficients.
The previous API used separate keyword arguments (
drag_coefficient,heat_transfer_coefficient,vapor_flux_coefficient), which made it awkward to pass coupled coefficient formulations likethe L&Y algorithm — where all three coefficients are computed together from a single set of
parameters. To resolve this, the three separate fields are replaced by a single
transfer_coefficientsfield that accepts either aSimilarityScalestuple (for independentconstant or callable coefficients) or a
LargeYeagerTransferCoefficientsobject (for thecoupled L&Y formulation). The
von_karman_constantis moved fromCoefficientBasedFluxesinto
LargeYeagerTransferCoefficients, where it is actually used.Changes
drag_coefficient,heat_transfer_coefficient,vapor_flux_coefficientwith a singletransfer_coefficientskeywordLargeYeagerTransferCoefficientsimplementing the full L&Y 2004/2009 algorithm with Monin-Obukhov stability corrections (OMIP-2 protocol)PolynomialNeutralDragCoefficientfor wind-speed-dependent neutral dragLinearStableStabilityFunctionandlarge_yeager_stability_functionsfor L&Y-style stability correctionsvon_karman_constantfromCoefficientBasedFluxesintoLargeYeagerTransferCoefficientsSimilarityScalesas the public container for transfer coefficientsNew API
References
Test plan
PolynomialNeutralDragCoefficient(bounds, cap, monotonicity, Float32)LinearStableStabilityFunctionandlarge_yeager_stability_functionsLargeYeagerTransferCoefficients